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Foreword 


The  Information  Processes  Group  (IPG)  of  the  Institute  for  Computer 
Sciences  and  Technology  (ICST)  was  created  in  1981  and  is  responsible  for, 
among  other  things,  the  development  of  methodologies  for  assessing  the  costs 
and  benefits  of  Federal  Information  Processing  Standards  (FIPS).  Almost 
immediately,  it  became  apparent  that  existing  cost  benefit  methodologies  were 
inadequate  to  the  purpose — partly  because  they  were  based  on  "rhetorical",  or 
idealized,  models  of  the  Federal  ADP  environment*  and  did  not  take  into 
account  the  multiplicity  of  operational  variations  among  the  agencies,  the 
complex  interactions  among  the  components  of  data  processing  system  management 
and  operations  (see  Figure  I-l),  or  the  sometimes  extreme  difference  between 
the  way  things  are  and  the  way  things  ought  to  be.     In  other  words,  existing 
methodologies  are  sufficient  for  "ball  park"  estimates,  but — particularly  in 
cases  where  anticipated  costs  and  benefits  are  less  than  enormous — the  expected 
margin-of-error  is  unacceptably  large. 

In  order  to  reduce  the  margin-of-error,  the  IPG  embarked  on  a  program  to 
describe  more  accurately  the  Federal  ADP  environment.     Using  functional  flow 
diagrams  as  the  basic  tool  for  description,  we  hope  eventually  to  have  a 
realistic  model  of  the  Federal  ADP  environment.     This  report  on  Data  Processing 
Operations  marks  the  completion  of  Phase  I  of  the  program.     Phase  II,  which 
covers  Software  Applications  Development,  is  currently  underway. 

The  bulk  of  the  work  on  this  project  was  done  by  Dr.  Marco  Fiorello  and 
Mr,  Peter  Eirich  of  Fiorello,  Shaw  and  Associates,  working  with  Aurora 
Associates,  Inc.     The  methodological  framework  was  developed  by  Peg  Kay  of  ICST. 
Like  most  of  the  IPG  projects,  results  were  obtained  and  validated  through 
considerable  interaction  with  personnel  from  other  Federal  agencies.     In  this 
case,  the  comments  and  suggestions  from  the  other  agencies  led  to  a  complete 
rethinking  and  revision  of  the  report  before  the  final  draft  was  completed. 
We  are  particularly  grateful  to  personnel  from  the  Department  of  Energy,  HUD, 
the  Department  of  Justice,  the  FCC,  the  Federal  Mediation  and  Conciliation 
Service,  the  FTC,  and  NASA  for  helping  to  shape  the  product. 

Simultaneously  with  this  attempt  to  improve  the  qualitative  descriptions,  the 
IPG  looked  for  ways  to  improve  the  analysis  of  statistics  concerning  the 
Federal  ADP  inventory.     The  first  product  of  that  effort  was  the  automation  of 
the  General  Services  Administration  (GSA)  data  base.     The  first  compilation 
and  analysis  based  on  the  automated  data  base  was  completed  in  June  1982.  As 
segments  of  the  qualitative  descriptive  models  are  completed,  it  is  our 
intention  to  apply  the  quantitative  analyses  to  them  and  gradually  to  improve 
the  accuracy  of  our  cost  benefit  projections. 


Another  serious  barrier  to  accurate  cost-benefit  projections  is  the 
absence  of  reliable  base-line  data.     This  series  of  reports  does  not  address 
that  issue. 
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While  this  program  is  primarily  directed  toward  the  improvement  of  ICST' s 
products,  it  is  clear  that  the  descriptive  models  being  developed  are  useful 
tools  for  ADP  managers  throughout  the  Federal  Government — and  probably  for  ADP 
managers  in  sub-Federal  jurisdictions  and  in  industry.    Their  usefulness  is 
not  confined  to  cost  benefit  related  studies,  but  is  applicable  to  a  host  of 
management  concerns  (e.g.,  reorganization,  workload  forecasting,  functional 
specifications  for  procurement,  and  so  on).     We  are  therefore  making  these 
reports  widely  available  in  the  NBS  Special  Publications  series. 

Questions  or  suggestions  related  to  the  program  are  welcome  and  should  be 
addressed  to  Peg  Kay,  Institute  for  Computer  Sciences  and  Technology,  Building 
225,  Room  B248,  National  Bureau  of  Standards,  Washington,  DC  20234. 
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ABSTRACT 


This  report  presents  a  set  of  functional-flow  descriptive  models  that  can 
be  used  to  categorize  the  operational  activities  of  Federal  data  processing 
users.     Data  processing  applications  may  be  conceptually  represented  in 
descriptive  model  form  by  combining  one  or  more  of  the  basic  models.  The 
comprehensive  framework  for  data  processing  operations  provided  by  these 
descriptive  models  can  be  used  in  the  identification  of  impacts  from  standards 
and  guidelines  and  in  the  preparation  of  cost-benefit  impact  assessments.  The 
framework  provides  both  macro  and  micro  levels  of  detail  in  order  to  link  the 
descriptive  models  to  additional  data  processing  issues,  such  as  computer 
security  issues. 

Key  words:     computer  security;  computer  standards;  cost-benefit  analysis;  data 
processing  management;  data  processing  operations;  data  processing  standards; 
descriptive  models;  impact  assessment;  information  systems. 
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I .  INTRODUCTION 


A.  General 

The  objective  of  this  Phase  I  report  is  to  present  and  describe  a  struc- 
ture for  a  "descriptive  model"  of  Federal  data  processing  (DP)  activities. 
By  a  descriptive  model  we  mean  a  qualitative  and  pictorial  (flowchart) 
portrayal  of  types  of  DP  activities  and  how  they  interrelate.     In  simple 
terms,  the  descriptive  model  presented  in  this  report  describes  "who  does 
what"  as  Federal  DP  operations  are  accomplished  by  computer  users.     In  order 
to  place  this  effort  in  perspective,  the  role  of  descriptive  models  in  the 
development  and  assessment  of  computer-related  standards  is  discussed  in  the 
next  section. 

B.  Background;     Evaluation  of  Standards 

Before  ICST  develops  a  standard  or  guideline,  an  assessment  of  the 
expected  costs  and  benefits  is  performed.     In  such  an  assessment,  the  analyst 
identifies  a  specific  set  of  changes  that  are  expected  to  occur  in  the  exist- 
ing and  projected  Federal  DP  environment  as  a  result  of  issuing  a  standard. 
The  dollar  consequences  of  those  changes  are  then  accumulated.     If  dollar 
amounts  for  projected  changes  cannot  be  estimated  or  imputed,  then  a  qualita- 
tive description  of  the  likely  impacts  is  provided,  along  with  a  commentary  on 
the  relative  desirability    or  undesir ability    of  the  results.     At  present, 
these  assessments  are  performed  in  accordance  with  a  1978  set  of  preliminary 
guidelines  [FIOR-78].    Appendix  A  summarizes  the  major  steps  in  the  assessment 
procedure. 

Implicit  in  the  analyst's  identification  of  projected  changes  is  a 
conceptual  model  of  DP  procedures,  an  expectation  of  how  government  agencies 
would  act  to  comply  with  the  standard,  and  an  idea  of  how  these  actions  would 
ultimately  affect  DP  systems  and  procedures  in  those  agencies.  Similar 
conceptual  models  are  implicit  when  standards  are  proposed  and  designed. 
While  portions  of  these  conceptual  models  are  sometimes  made  explicit  in  assess- 
ment reports  or  standards  design  documents,  there  is  no  uniform  vocabulary  or 
framework  in  use  to  evaluate  standards.    Without  a  framework,  it  is  difficult 
either  to  compare  the  impacts  of  different  standards  or  to  be  confident  that 
supporting  data  have  been  employed  consistently  from  one  assessment  to  the 
next . 

A  recent  review  of  six  impact  assessments  [FIOR-81],  each  completed  in 
accordance  with  the  1978  preliminary  guidelines,  made  several  points  relevant 
to  the  above  discussion. 

o    The  analyses  tended  to  focus  exclusively  on  the  components  or  parts 
of  the  ADP  system  or  process,  and  not  mention  the  relevant  procedures 
and  management  actions  that  must  occur  to  achieve  the  impact  modeled, 
(p.  9) 

o    The  interpretation  of  the  nature  of  impacts  was  inconsistent  across 
the  studies,  (p.  10) 
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The  review  recommended  that  the  impact  assessment  guidelines,  when  revised, 
should: 

o    Improve  the  discussion  of  the  formulation  of  the  base  case  and 
impact  process.     The  explicit  use  of  scenario  constructs  and  a 
descriptive  model  (functional  diagrams  with  unifying  flows)  should  be 
introduced,  (p.  12) 

An  important  benefit  of  this  modeling  effort  will  be  to  replace  the 
analyst's  implicit  mental  models  with  an  explicit,  documented,  and  commonly 
understood  representation  of  Federal  DP  activities.    This,  in  turn,  will  help 
to  insure  consistency  among  the  different  impact  assessments  of  standards 
performed  for  ICST.     It  will  also  permit  comparisons  among  the  expectations  of 
standards  developers,  the  benefits  projected  in  the  impact  assessment,  and  the 
actual  benefits  that  may  be  computed  after  a  standard  has  been  implemented. 

C.  Project  Goals 

The  end-product  of  the  overall  descriptive  model  effort  will  be  a  set  of 
functional-flow  descriptive  models  providing  a  comprehensive  representation 
of  Federal  DP  activities.     Using  this  framework,  it  will  be  possible  to 
specify  the  impacts  of  different  standards,  collect  data  organized  so  as  to 
aid  impact  assessments,  and  define  points  of  measurement  for  evaluating  a 
standard's  actual  benefits. 

The  Phase  I  descriptive  model  developed  in  this  report  can  be  applied 
immediately  to  the  development  of  a  cost-effective  set  of  computer-related 
standards  and  guidelines.     For  example,  it  can  improve  planning  for  ICST 
products  by  identifying  the  types  of  personnel  to  be  affected  by  a  proposed 
standard  or  guideline.     Improved  standards  will,  in  turn,  assist  computer 
system  and  application  managers  to  do  a  better  job  of  developing  and  monitor- 
ing DP  systems. 

D.  Scope  of  the  Phase  I  Effort 

The  descriptive  model  is  intended  to  encompass  the  breadth  of  DP  system 
management  and  operation  represented  in  Figure  I-l.    The  scope  of  this  Phase  I 
effort  is  limited  to  the  "Data  Processing  Operations"  portion  of  the  Figure. 
The  existence  of  hardware,  system  software,  and  applications  software  is  taken 
for  granted,  and  we  do  not  develop  descriptive  models  for  how  those  resources 
came  to  exist  in  the  right  place,  at  the  right  time.    The  same  is  true  for 
staff  and  management  personnel,  security  controls,  data  resources  controls, 
office  space,  etc. 

This  Phase  I  model  is  only  a  first  step  toward  a  comprehensive  set  of 
Federal  DP  descriptive  models.     Later  study  phases  will  develop  models  compar- 
able to  this  one  for  the  other  areas  shown  in  Figure  I-l.    Also,  this  Phase  I 
model  will  be  further  refined  as  it  is  used  for  cost-benefit  studies  and  as  it 
serves  as  a  basis  for  statistical  data  collection. 
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The  Phase  I  effort  has  identified  and  defined  a  generic  set  of  independent 
functional  flow  modules,  or  "building  blocks",  for  DP  operations.     For  each 
module,  the  descriptive  model  of  DP  operations  specifies  functional  flows  for 
the  activities  comprising  operations.     These  modules  can  be  assembled  in 
different  combinations  to  represent  consistently  the  variety  of  general-purpose 
DP  applications  in  the  Federal  Government.!     The  "unifying  flow"  for  our 
description  is  the  transformation  of  data  items  into  both  useful  information 
and  output  products  in  the  course  of  DP  processing  operations.     (The  concept 
of  a  unifying  flow  is  discussed  in  Chapter  II.) 

The  accuracy  and  completeness  of  representation  was  verified  by  a 
process  of  review  by  a  number  of  Federal  data  processing  managers  —  a  process 
that  will  be  repeated  during  the  development  of  comparable  descriptive  models 
for  the  acquisition  and  development  of  hardware,  systems  software,  and  applica- 
tions software.     Later  phases  of  this  study  effort  will  also  treat  broader 
concerns  such  as  the  selection  and  implementation  of  security  procedures,  data 
resources  planning,  and  overall  DP  system  management.     The  software  applica- 
tions development  process  will  be  the  topic  of  the  Phase  11  effort. 

E.      Overview  of  this  Report 

Chapter  II  presents  the  concept  of  a  descriptive  model  composed  of 
modular,  functional-flow  building  blocks,  or  subsystems.     It  identifies  the 
set  of  subsystems  employed  in  the  model  and  describes  their  interrelation- 
ships . 

Chapter  III  describes  each  subsystem  and  introduces  the  subsystem 
flow  diagrams.     Chapter  IV  discusses  how  the  subsystems  may  be  combined  to 
represent  different  complete  DP  applications,  and  compares  the  subsystem 
operational  characteristics. 

The  subsystem  concept  is  expanded  in  several  ways  in  Chapter  V.  First, 
the  use  of  subsystem  functional  flows  to  organize  more  macro  and  more  micro 
levels  of  detail  is  described.     Second,  security  considerations  are  related  to 
these  levels  of  detail.    Third,  the  use  of  subsystem  flows  to  organize  data 
for  planning  and  assessing  standards  is  discussed.     Finally,  the  use  of  the 
flow  diagrams  as  a  presentation  medium  is  illustrated. 


Our  objective  is  to  adequately  cover  the  broad  range  of  general-purpose 
DP  activities,  while  keeping  the  total  number  of  modules  small  and  manage- 
able.    Accordingly,  we  do  not  include  embedded  weapons  systems  computers 
in  the  scope  of  this  descriptive  model,  nor  do  we  intend  to  cover 
relatively  unique  special-purpose  applications  not  typical  of  the  federal 
government  as  a  whole.     For  example,  the  magnetic  ink  character  recogni- 
tion (MICR)  equipment  used  the  Federal  Reserve  for  sorting  checks  is  not 
covered  by  any  of  the  modules. 
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Chapter  VI  summarizes  the  work  covered  in  this  report,  and  describes 
the  steps  to  be  undertaken  in  Phase  II.     Appendix  A,  as  mentioned  earlier, 
summarizes  the  basic  steps  in  performing  a  standards  impact  assessment  as 
described  in  the  1978  preliminary  guidelines  [FIOR-78].    Appendix  B  contains 
the  flow  diagrams  for  the  different  subsystems. 
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II,     DESCRIPTIVE  MODEL  CONCEPT 


A.  General 

This  chapter  explains  the  principle  on  which  the  descriptive  model  of 
DP  operations  is  based  and  how  the  subsystem  approach  to  categorizing  DP 
activities  was  chosen.    The  13  subsystems  and  their  interactions  are 
introduced  c 

Bo      The  Unifying  Flow  Principle 

A  descriptive  model,  as  the  term  is  used  here,  traces  a  sequence  of 
events  or  processing  steps  in  a  system  or  organization.    The  key  to  preparing 
a  descriptive  model  that  captures  the  essence  of  a  system  or  organization,  and 
portrays  it  in  a  straightforward  manner,  is  to  identify  the  proper  "unifying 
flow"  for  the  model  [NAKA-82], 

The  basis  for  a  unifying  flow  is  some  item  or  characteristic  that  can 
be  traced  throughout  the  system  or  organization  to  be  modeled.    The  unifying 
flow,  specifically,  is  the  path  taken  by  the  selected  item  or  characteristic 
and  is  the  basis  for  organizing  the  descriptive  model.    For  the  model  of  DP 
operations  developed  in  this  report,  the  unifying  flow  is  the  transformation 
of  data  into  information  in  the  course  of  DP  activities.     Information  may  take 
the  form  of  outputs  used  for  decision-making,  or  of  specific  output  products 
(for  instance,  Social  Security  checks). 

Our  broad  view  of  DP  likens  it  to  an  information  factory,  where  various 
types  and  amounts  of  raw  data  are  pumped  in,  various  things  are  done  to  them 
and  various  useful  information  comes  out.     One  must  know  who  uses  the  informa- 
tion, and  why  it  is  considered  information  instead  of  data,  in  order  to 
understand  the  role  of  DP  in  an  organization.     One  must  also  understand  the 
nature  of  the  data  submitted  for  processing,  as  well  as  what  is  done  to  them, 
and  by  whom,  to  understand  the  functioning  of  DP  operations.    All  these 
elements  belong  to  the  descriptive  model  and  are  keyed  to  the  unifying  flow  of 
"data  into  information", 

C.      Overall  Model  Structure 

The  range  of  Federal  DP  activities  is  too  broad  to  be  represented  in  a 
useful  way  by  any  one  Integrated  descriptive  model.    Accordingly,  our  approach 
was  to  develop  a  set  of  related  descriptive  models  that  could  be  combined  in 
different  ways  to  reflect  the  wide  variety  of  Federal  DP  activities.  To 
create  a  workable  set  of  models  it  was  necessary  to  categorize  DP  activities 
in  such  a  way  that,  for  each  category,  a  single  model  could  be  developed  which 
would  apply  reasonably  well  to  the  various  activities  within  the  category. 

A  number  of  likely  categorization  schemes  had  to  be  rejected  for  a 
variety  of  reasons.     For  instance,  while  there  are  many  similarities  in  DP 
activities  among  different  agencies,  there  are  still  too  many  differences  to 
allow  building  a  descriptive  model  for  one  agency  and  applying  it  (with  only 
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minor  variations)  government-wide.     As  another  example,  models  based  on 
functions  (personnel,  accounting,  supply)  were  not  practical  because  there  are 
too  many  possible  variations  for  any  one  function  to  have  only  one  model  for 
each,  and  yet  there  are  enough  similarities  between  different  functions  to 
make  the  models  repetitive  in  many  cases. 

Breakdowns  based  on  any  of  the  resources  shown  in  Figure  I-l  were 
rejected  for  similar  reasons.  These  possibilities  included  breakdowns 
by: 

o    computer  hardware  used 

o    system  software  environment 

o    application  software  characteristics 

o    security  requirements 

o    staff /position  characteristics  of  users 
o    size  of  organization 

Management-oriented  breakdowns  were  also  not  satisfactory.     In  a  study 
of  56  decision-oriented  computer  applications^  Steven  Alter  found  that  few 
significant  conclusions  seemed  to  emerge  from  commonly-used  labeling  schemes 
such  as : 

o    functional  area  (marketing,  production,  finance,  etc.) 

o    decision  perspective  (operational  control,  management  control, 
strategic  planning) 

o    problem  type  (structured  vs.  unstructured) 

o    computer  technology  (interactive  vs.  batch) 

o    modeling  approach  (simulation  vs.  optimization) 

The  breakdown  ultimately  selected  for  our  descriptive  model  is  an 
expansion  of  Alter' s  work  [ALTE-75;  ALTE-77].     Alter  found  that  seven  "system 
types"  served  as  a  useful  classification  scheme  for  the  56  applications  he 
studied.     In  a  broader  context,  Alter' s  "systems"  may  be  viewed  as  subsystems 
of  still  larger  DP  applications,  and  13  such  subsystems  are  needed  to  represent 
the  breadth  of  general-purpose  DP  activities  in  the  Federal  Government. 


Presumably,  most  or  all  of  them  were  in  the  private  sector.     See  [ALTE-77, 
pp.  40-41].     Labeling  schemes  for  applications  reprinted  with  permission 
(see  references) . 
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The  set  of  data  processing  operations  subsystems  is  as  follows: 


1. 

Transaction  Data  Capture 

2. 

Transaction  Data  Aggregation 

3. 

Recordkeeping 

4. 

Transaction  Disbursement 

5. 

Technical  Data  Preparation 

6. 

Automated  Data  Capture 

7. 

Analysis  and  Reporting 

8. 

Data  Retrieval  and  Analysis 

9. 

Data  Combination,  Analysis,  and  Reduction 

10. 

Specialized-Data  Model  Execution 

11. 

Integrated-Data  Model  Execution 

12. 

Computer-Aided  Task  Performance 

13. 

Software  Development 

Subsystems  7  through  11  cover  the  scope  of  systems  studied  in  [ALTE-75;  ALTE-77]. 
We  have  redefined  his  categories  to  reflect  the  structure  of  the  DP  operations 
involved  rather  than  following  Alter' s  definitions,  which  reflect  system 
behavior  and  intent.    While  this  regrouping  of  applications  is  more  appropriate 
for  the  analysis  of  ongoing  DP  activities,  the  discussion  of  subsystems  also 
refers  to  Alter' s  categories  in  order  to  benefit  from  his  research  results. 

D.      Subsystem  Interactions 

Different  subsystems  may  be  combined  to  form  various  DP  applications.  In 
general,  some  subsystems  will  typically  perform  input  processing,  while  others 
will  primarily  prepare  output  products.     This  can  never  be  completely  true, 
of  course,  since  the  output  of  one  DP  system  is  often  the  input  to  the  next. 

Figure  II-l  shows  the  manner  in  which  subsystems  are  generally  inter- 
connected.    Types  of  intermediate  files  that  serve  to  transfer  data  from  one 
subsystem  to  the  next  are  also  shown.     Again,  this  is  not  the  only  pattern  of 
interconnection  possible, ^  but  we  believe  it  is  the  most  typical. 

Subsystem  interconnections  will  be  treated  further  in  Chapter  IV,  where 
DP  applications  are  discussed.     First,  a  more  detailed  description  of  each 
subsystem  will  be  presented  in  Chapter  III. 


Some  additional  types  of  interconnections  are  indicated  in  the  sub- 
system flow  diagrams  in  Appendix  B. 
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III.     SUBSYSTEM  DESCRIPTIONS 


A.  General 

This  chapter  briefly  defines  and  describes  each  of  the  13  subsystems 
mentioned  in  Chapter  II  and  introduces  the  subsystem  models.     These  descrip- 
tions establish  the  role  of  each  subsystem  in  the  overall  DP  scheme  to  prepare 
for  the  explanation  of  DP  applications  and  operational  characteristics  in 
Chapter  IV. 

B.  Subsystem  Descriptions 

1«     Transaction  Data  Capture:     the  entry  of  data  from  individual  transac- 
tion documents  such  as  accounting  vouchers  onto  machine-readable  media  for 
further  processing.    The  results  of  this  procedure  are  a  set  of  files,  reflect- 
ing the  relevant  transaction  data,  residing  on  various  processing  media,  and 
accompanied  by  physical  documents  and  control  totals  (as  necessary)  to  provide 
an  audit  trail.    The  resulting  files  are  generally  forwarded  for  processing 
under  a  subsystem  2  application  (transaction  data  aggregation). 

Examples  include  accounting,  inventory,  and  timekeeping  document  entry, 
as  well  as  the  entry  of  corrections  for  errors  detected  in  later  stages  of 
processing. 

2.  Transaction  Data  Aggregation:     the  collection  of  individual  transac- 
tion records,  when  the  data  entered  are  essentially  additive  or  cumulative  in 
effect.     The  results  of  this  collection  are  usually  a  set  of  master  files 
updated  for  a  given  period  and/or  a  set  of  merged  transaction  files  for 

the  period. 

Besides  various  accounting  vouchers  where  dollar  amounts  are  cumulated, 
other  examples  of  transaction  aggregation  are  found  in  inventory  control, 
where  stock  additions/withdrawals  are  tracked  to  adjust  stock  balances,  and 
in  employee  timekeeping,  where  staff  hours  by  project  are  accumulated. 

3.  Recordkeeping :     the  processing  of  transactions,  which  take  the  form  of 
updates  or  changes  to  information  in  master  files  (3a — on-line,  deferred  update) 
and/or  updates  to  an  on-line  data  base  (3b — on-line,  immediate  update).  Note 
that  maintenance  of  historical  data  in  a  file,  such  as  previous  position  titles 
and  past  salaries  for  an  employee  in  a  personnel  file,  does  not  make  these  data 
cumulative  in  the  sense  of  subsystem  2  (transaction  data  aggregation). 

Examples  may  be  found  in  payroll  and  personnel  systems,  where  changes  to 
employee  status  or  salary  and  additions/deletions  of  employees  are  processed. 
Other  examples  are  payment  systems  such  as  Social  Security  where  trans- 
actions entered  from  field  offices  are  used  to  change  master  files  and  thereby 
initiate,  terminate,  or  change  computed  beneficiary  pa3nnents. 

4.  Transaction  Disbursement:     the  preparation  of  transaction  documents 
to  be  distributed,  as  opposed  to  collected. 
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The  most  obvious  example  is  the  preparation  of  checks,  which  may  be 
computed  and  prepared  on  the  basis  of  transaction  files,  master  files,  or  a 
combination  of  the  two.     Payroll  systems  are  an  example  of  a  combination  of 
both  sources,  since  computation  of  the  amount  of  each  check  for  a  pay  period 
often  depends  on  both  the  timekeeping  data  for  the  pay  period  (from  a  type  2 
transaction  data  aggregation  subsystem)  and  the  employee  master  file  (from  a 
type  3  recordkeeping  subsystem) . 

5.  Technical  Data  Preparation;     the  maintenance  of  data  files  by 
technical  personnel,  typically  for  use  as  inputs  to  computer  models.  Unlike 
the  previous  four  subsystems,  which  generally  involve  formal  processing 
controls  and  audit  trails,  the  integrity  of  the  data  in  this  subsystem  relies 
upon  the  concern  and  attention  to  detail  of  the  responsible  analyst.  Data 
maintenance  will  usually  be  accomplished  with  a  generalized  text  editor, 

in  contrast  to  the  program-controlled  or  data  base  management  system  (DBMS)- 
controlled  updates  found  in  subsystem  3  (recordkeeping). 

Examples  are  data  preparation  for  all  manner  of  engineering,  scientific, 
and  economic  models.    Maintenance  procedures  will  usually  be  more  formalized 
for  either  large-scale  models  or  models  where  the  results  are  widely  publicized. 

6.  Automated  Data  Capture:     the  processing  of  a  stream  of  real-time  or 
recorded  data  samples  to  determine  what  events  of  interest  have  transpired 
and  to  report  those  events  in  a  usable  (or  readable)  format.    This  type  of 
subsystem  is  typically  found  in  manufacturing  and  engineering  applications  and 
represents  only  a  "front-end"  conversion  step  to  provide  inputs  for  other 
subsystem  processing. 

Examples  include  the  processing  of  satellite  transmissions  and  the 
analysis  of  recorded  data  from  engineering  field  tests.     The  latter  can 
include  both  environmental  data  such  as  underwater  sound  recordings  and/or 
internal  system  information  such  as  the  outputs  from  electronic  circuitry  or 
micro-computers  that  implement  decision  logic. 

7.  Analysis  and  Reporting:     primarily  the  preparation  of  routine, 
standard,  periodic  reports,  using  batch  computer  programs,  on  a  wide  variety 
of  activities  in  the  organization.     (Often  these  are  called  "vanilla  COBOL" 
applications  when  COBOL  is  the  programming  language.)    They  can  also  be 
sophisticated  reporting  systems  utilizing  a  DBMS  or  other  advanced  technique. 

The  term  "analysis"  reflects  limited  manipulation  of  the  data  (in 
addition  to  straightforward  summary)  which  may  be  performed  to  simplify  use 
of  the  report's  contents.    When  these  manipulations  take  the  form  of  evaluat- 
ing simple  decision  rules,  this  subsystem  can  implement  a  "decision  suggestion" 
function  wherein  specific  managerial  or  operational  actions  are  indicated  by 
the  results  of  a  computer  program.  ^ 


Suggestion  models  represent  one  decision  support  system  type,  as  defined 
by  Alter  [ALTE-75;  ALTE-77],  that  may  be  implemented  by  several  of  the 
operational  subsystems  (7,  10,  11)  presented  here. 
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Examples  include  summary  reports  of  expenses  and/or  staff  hours  by 
project,  employee,  branch,  division,  etc.     Such  reports  may  be  found  in  almost 
every  sizeable  organization.    Examples  of  decision  suggestion  reports  are:  a 
list  of  employees  due  for  a  step  increase  on  the  basis  of  time-in-grade  and  an 
inventory  list  flagging  items  with  stock-on-hand  below  the  appropriate  reorder 
point . 

8.  Data  Retrieval  and  Analysis;     the  preparation  of  data  listings  and/or 
processed  reports  at  the  initiation  of  the  end-user.     This  generally  implies 
on-line,  interactive  access,  although  batch  programs  may  be  used  in  lieu  of  (or 
in  addition  to)  on-line  access.     The  two  major  usage  modes  for  this  subsystem, 
data  item  display  and  data  analysis,  are  characterized  below, 

/ 

8.1  Data  Item  Display — the  retrieval  of  status  information  or  other  data 
concerning  specific  items.     The  data  may  be  stored  in  forms  ranging  from 
sequential  files  on  off-line  media  to  on-line  data  bases;  the  key  here  is  that 
only  a  simple  "file  drawer"  type  of  retrieval  is  done,  with  minimal  (if  any) 
aggregation  of  data.     Inquiries  can  be  either  ad  hoc,  or  operational  and 
repetitive . 

Examples  include  the  retrieval  of  on-hand/on-order  information  for 
inventory  items,  status  information  on  project  expenditures,  and  employee  data 
from  a  personnel  database. 

8.2  Data  Analysis — the  preparation  of  a  variety  of  ad  hoc  or  special- 
purpose  reports  by  supplying  input  parameters  to  customized  software  or  using 
user-oriented  data  manipulation  languages.     This  includes  both  generalized 
data  manipulation  languages,  such  as  the  query  langauges  often  incorporated 
into  a  DBMS,  and  specialized  languages  dealing  with  specific  job  or  task.  The 
data  could  be  stored  in  various  file  structures  or  maintained  under  a  DBMS. 

While  data  item  display  involves  the  retrieval  and  display  of  individual 
records,  data  analysis  typically  presents  aggregate  data  derived  from  sets  of 
selected  records.     For  instance,  a  data  item  display  program  might  print  all 
the  outstanding  orders  for  a  specified  vendor,  while  a  data  analysis  program 
might  provide  the  total  amount  of  outstanding  orders  overdue  by  30  days  and  a 
breakdown  by  vendor. 

A  variety  of  examples  often  may  be  found  wherever  a  DBMS  has  been 
installed,  depending  only  on  the  needs  and  skills  of  the  DBMS  users.  Other 
examples  include  the  use  of  customized  software  to  provide  tabular  reports  on 
research  project  expenditures.     In  this  example  the  user  supplies  the  variables 
to  be  summarized,  and  the  tailored  software  determines  the  row  and  column 
headings,  retrieves  the  appropriate  data  records,  and  produces  the  desired 
summary  table. 

9.  Data  Combination,  Analysis,  and  Reduction;     the  preparation  of 
intermediate  data  files  and/or  special-purpose  reports  requiring  data  from 
more  than  one  operational  DP  system  and/or  management  database.  The 
software  that  makes  this  possible  may  be  viewed  as  a  collection  of  models 
and  data  utilities  that  can  be  applied  by  an  analyst  to  gather  data  from 
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different  systems  and  to  perform  planning  calculations.     Such  systems  often 
require  cooperation  between  different  software  groups,  different  managers, 
and/or  different  organizations  for  successful  operation  and  may  be  operated 
on  a  periodic  or  ad  hoc  basis. 

One  example  is  a  system  that  extracts  and  integrates  data  from  several 
logistics  reporting  systems,  containing  different  types  of  information,  and 
prepares  a  specialized  database.     This  specialized  database  can  then  be  used 
to  provide  summary  reports  for  decision-making  and  also  to  generate  data  for 
computer  models  of  the  types  listed  below. 

10.     Specialized-Data  Model  Execution:     the  use  of  models  that  operate 
from  "constructed"  databases,  such  as  the  output  files  from  either  subsystem 
5  (technical  data  preparation)  or  9  (data  combination,  analysis,  and  reduction), 
that  will  usually  be  tailored  to  the  needs  of  the  particular  model.  These 
models  will  typically  be  used  for  planning,  analysis,  and  problem-solving,  and 
will  often  be  set  up  for  use  by  specialists  on  an  as-needed  basis.     While  any 
of  the  model  types  described  in  [ALTE-75;  ALTE-77]  could  fall  into  this 
category,  accounting  models  and  representational  models  are  (we  believe)  more 
commonly  found  here  and  will  be  characterized  below,  while  optimization 
models  and  suggestion  models  are  covered  under  subsystem  11  (integrated-data 
model  execution) . 

10.1.     Accounting  Model  Computation — the  use  of  standardized  formulas  and 
relationships  to  prepare  estimates  for  management  planning  and/or  operations 
activity.     These  are  frequently,  but  not  exclusively,  accounting/financial 
estimates, 2    As  compared  to  type  8.2  subsystems  (data  analysis),  the  computa- 
tions utilized  involve  more  than  simple  accumulations  or  statistical  summaries 
of  stored  data,  and  more  than  straightforward  decision  rules  applied  to  such 
summaries,  but  are  restricted  to  cases  where  the  computational  relationships 
are  tightly  defined  or  well-known,  even  though  model  parameters  may  vary.  The 
"stable"  algorithms  involved  make  these  models  suitable  for  decision  suggestion 
applications,  and  they  may  be  utilized  for  this  purpose  as  described  under 
subsystem  11  (integrated-data  model  execution). 

An  example  is  the  calculation  of  estimated  retirement  benefits  for  an 
employee,  on  the  basis  of  salary  and  length-of-service  data,  using  different 
date-of-retirement  assumptions.     Other  examples  would  be  the  computation  of 
project  cost  estimates  based  on  estimated  staff  hours  for  different  skill 
levels,  project  status  reporting,  and  budget  projections. 

10.2    Representational  Model  Simulation — the  use  of  mathematical  models 
to  represent  more  complex  processes  than  might  be  handled  by  a  simple  account- 
ing model,  and  to  predict  outcomes  on  the  basis  of  either  varying  system 
inputs,  or  making  different  assumptions  concerning  the  process  modeled  and/or 
the  nature  of  relationships  between  variables.     These  models  are  often  used  for 


We  use  the  term  "accounting-model"  because  it  best  exemplifies  the 
type  of  computations  performed.     The  term  does  not  imply  that  subsystem 
10.1  is  found  only  in  accounting  applications. 
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engineering  design  decisions,  and  for  other  problems  that  cannot  be  treated  by 
one  or  more  definitional  formulas  like  those  covered  by  accounting  model 
computation.     In  these  problems  the  interactions  between  formulas  and  the 
amounts  of  computation  are  such  that  a  computer  is  required,  whereas,  in  an 
accounting  model,  it  might  be  merely  convenient. 

An  example  is  the  computer  simulation  of  the  responses  of  a  proposed  wea- 
pon system  in  different  operational  environments,  such  as  the  performance  of  a 
sonar  system  at  different  depths  and  under  different  ocean  temperature-gradient 
conditions.    Another  example  is  the  simulation  of  the  survivability  of  a  ship 
under  different  forms  of  attack. 

11.     Integrated-Data  Model  Execution:     the  use  of  models  that  operate 
directly  from  operational  data  files  or  from  slightly  processed  versions  of 
those  files,  as  opposed  to  tailored  and/or  highly  aggregated  data  bases  (such 
as  those  utilized  for  models  in  subsystem  10).    While  specialized-data  models 
will  often  involve  aggregate  data  inputs,  integrated-data  models  will  generally 
operate  on  detailed  data  and  take  the  form  of  decision  suggestion  or  trade-off 
optimization  models. 

11.1  Decision  Suggestion:     the  use  of  a  mathematical  algorithm  to  indicate 
managerial  or  operational  actions.     The  basis  could  be  mathematical  optimiza- 
tion, accounting  model  computations,  or  other  decision  rules.    The  expectation 
is  that  the  computer-produced  suggestions  would  be  implemented,  but  only  so 
long  as  the  situation  remains  within  the  bounds  of  the  circumstances  for  which 
the  suggestion  model  was  originally  designed. 

An  example  would  be  a  student/class  scheduling  model  for  a  military 
training  school. 

11.2  Trade-off  Optimization — the  use,  for  planning  purposes,  of 
mathematical  models  that  find  the  combination(s)  of  resources  or  system 
parameters  that  maximize  or  minimize,  within  specified  constraints,  the  value 
of  some  selected  goal  variable.    These  models  can  be  used  to  evaluate  design 
or  management  trade-offs  as  the  constraints  are  varied.     In  contrast  to  a 
decision  suggestion  model,  which  may  use  optimization  techniques  to  produce 

a  specific  answer,  trade-off  optimization  implies  that  information  about 
constraints,  sensitivities,  and  input  trade-offs  is  reviewed  and  analyzed 
in  addition  to  the  optimization  results,  and  different  scenarios  may  be 
evaluated. 

An  example  is  the  determination  of  the  mix  of  spare  parts  that  provides 
the  maximum  expected  aircraft  availability  for  any  specified  level  of 
additional  investment  in  spare  parts.     The  results  of  such  a  model  enable 
managers  to  understand  the  effects  of  more  or  less  investment  in  spare  parts 
and  to  make  better  decisions  concerning  the  trade-offs  between  the  amounts 
invested  in  spare  parts  and  other  forms  of  investment  such  as  new  aircraft. 
Once  the  level  of  expenditure  for  spare  parts  has  been  determined,  the 
optimization  model  can  be  used  like  a  decision  suggestion  model  in  order 
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to  specify  which  particular  spare  parts  should  be  purchased, 3  Alternatively, 
when  used  to  predict  the  availability  rate  that  will  result  from  a  specified 
level  of  investment,  the  model  is  used  as  a  representational  model.     (In  the 
latter  use,  one  assumption  is  that  dollars  will  be  spent  optimally  in  terms  of 
availability.) 

12.  Computer-Aided  Task  Performance;     the  use  of  a  computer  to  enhance 
the  ability  of  a  person  to  perform  a  task  by  executing  various  operations 
under  immediate  and  interactive  control  by  that  person.     Included  here  are  any 
applications  where  the  computer  acts  to  extend  the  capabilities  of  the  user  to 
perform  some  task  in  a  real-time  manner.     Both  printing  and  CRT  terminals, 
with  or  without  graphics  capabilities,  may  be  used. 

An  example  is  the  use  of  computerized  drafting  systems  where  the  computer 
constructs  drawings  on  the  basis  of  real-time  instructions  from  a  draftsman. 
Computer-aided  design  applications  such  as  electronic  circuit  and  mechanical 
component  design  can  result  from  integrating  this  subsystem  with  a  represent- 
ational model  simulation  (subsystem  10.2).    Word  processing  systems  and 
of f ice-of-the-f uture  technology  in  general  also  belong  under  this  subsystem. 

13.  Software  Development;     the  use  of  text  editors,  compilers,  and  other 
system  utilities  to  prepare  either  application  programs,  computer  system 
software,  or  job  control  language.     The  result  of  this  subsystem  is  the 
variety  of  programs  and  control  statements  necessary  to  implement  instances 

of  the  previous  12  subsystems.    We  include  in  this  subsystem  only  those 
activities  that  directly  involve  DP  operations;  other  aspects  of  software 
development  (e.g.,  planning,  meetings,  documentation)  are  covered  under  the 
Phase  II  descriptive  model,  which  also  encompasses  the  elements  of  this 
software  development  subsystem. 

Examples  include  all  types  of  programs  given  as  examples  under  subsystems 
1  through  12.     These  may  be  written  in  commonly  used  languages  such  as 
FORTRAN,  COBOL,  PL/1,  and  BASIC,  or  may  be  developed  using  special-purpose 
languages  such  as  DBMS  query  commands. 

C.     Subsystem  Models 

Flow  diagrams  for  the  13  subsystems  may  be  found  in  Appendix  B.     Each  is 
a  fundamental  building  block  of  the  DP  operations  descriptive  model. 

Each  diagram  follows  the  transformation  of  data  to  information  within 
a  subsystem.     The  figures  show  the  different  media  and  representations  used 
for  the  data  at  different  stages  of  processing,  while  still  maintaining  fairly 
general  descriptions  concerning  the  nature  of  the  data.    Each  figure  shows 
major  steps  in  processing  and  the  personnel  that  directly  interact  with  the  DP 
system  or  the  data. 


In  practice,  the  suggested  purchases  are  seldom  followed  exactly  because  of 
localized  constraints  and  miscellaneous  "real-world"  factors  that  managers 
take  into  account  when  placing  an  order. 
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Decimal  numbers  are  used  for  the  figures  in  Appendix  B.    The  numerical 
portion  represents  the  subsystem  number.    A  lower-case  letter  in  the  figure 
number  indicates  that  the  diagram  is  one  of  several  common  variations  for  the 
particular  subsystem.     Such  variations  occur  when  different  computer  tech- 
nologies cause  significant  changes  in  the  processing  flow.  Differences 
between  batch  and  interactive  processing,  for  example,  are  reflected  within 
each  figure  as  appropriate.    When  variations  due  to  technology  are  minor, 
these  are  simply  noted  on  the  primary  diagram. 

Taken  together,  these  subsystems  represent  the  major  variations  of 
processing  found  in  general-purpose  DP  activities  in  the  Federal  Government, 
They  should  be  reviewed  before  proceeding  to  the  next  chapter,  which 
illustrates  how  DP  applications  may  be  represented  by  combinations  of  the 
subsystems . 


16 


IV.     DATA  PROCESSING  APPLICATIONS 


A.  General 

This  chapter  begins  by  discussing  the  structural  relationship  between 
applications  and  the  set  of  DP  subsystems.     The  subsystems'  operational 
characteristics  are  then  compared.     Our  non-rigorous  definition  of  an 
application  is:     a  sequence  of  DP  procedures  that  begins  with  some  user  data 
or  computer  files  that  exist  independently  (they  are  not  simply  intermediate 
by-products  of  a  processing  sequence)  and  ends  with  printed  outputs  or 
computer  files  that  serve  a  definite  organizational  purpose. 

B.  Application  Illustrations 

In  the  descriptive  model,  applications  are  considered  as  combinations  of 
subsystems  linked  by  intermediate  products  of  the  processing  sequence.  For 
example,  as  illustrated  in  Figure  IV-lj  a  minimal  accounting  voucher  applica- 
tion usually  consists  of  transaction  data  capture  and  aggregation  subsystems 
to  prepare  a  weekly  transaction  file,  and  an  analysis  and  reporting  subsystem 
to  turn  out  weekly  (or  periodic)  summary  reports.     There  is  little  transforma- 
tion of  data  into  information  —  the  output  reports  are  simply  recapitulations, 
with  totals,  of  the  input  documents.     The  subsystems  are  linked  by  a  well- 
defined  intermediate  product  —  a  file  containing  the  accumulated  weekly 
transactions  (typically  grouped  into  batches  of  transactions,  with  batches  in 
sequence  according  to  an  assigned  control  number).     The  intermediate  file  is 
shown  as  stored  on  tape,  since  we  believe  this  to  be  the  most  common  practice, 
but  the  application  would  not  be  affected  if  disk  storage  were  used.  1 

As  indicated  in  Figure  IV-1 ,  intermediate  products  can  be  shared  among 
applications.     As  a  result,  drawing  the  boundaries  between  different  applica- 
tions can  be  somewhat  arbitrary  and  can  vary  from  organization  to  organiza- 
tion.    As  a  general  rule,  the  boundaries  of  applications  will  be  drawn 
along  lines  of  management  responsibility     (for  the  data  and  products)  at  some 
level  in  the  organization.     In  this  example,  the  accounting  department  "owns" 
(i.e.,  controls)  both  the  input  vouchers  and  output  reports. 

In  general,  application  diagrams  may  be  formed  as  subsets  of  the  subsystem 
interactions  diagram  shown  earlier  as  Figure  II-l.    For  example,  a  basic 
personnel  application  would  consist  of  subsystems  3  and  7  —  a  record- 
keeping subsystem  to  maintain  the  employee  master  file  and  an  analysis 
and  reporting  subsystem  to  prepare  periodic  staffing  reports.    However,  other 
subsystems  using  the  employee  master  file  as  input  may  also  be  found  in 
personnel  applications,  as  follows: 


Where  the  type  of  media  is  important  to  the  nature  of  processing,  such 
as  the  need  for  disk  storage  when  random  access  is  required,  it  will  be 
specifically  noted. 
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o    a  transaction  disbursement  subsystem  may  be  included  to  produce 
standard  personnel  action  forms  for  filing  in  employee  folders  (as 
opposed  to  personnel  systems  that  use  these  forms  as  input  documents); 

o    a  data  retrieval  and  analysis  subsystem  may  be  used  for  simple  on-line 
inquiries  regarding  employee  status; 

o    a  data  retrieval  and  analysis  subsystem  may  provide  infrequent  or 
ad  hoc  reports  for  a  specific  manager; 

o    a  representational  model  in  a  specialized-data  model  subsystem  can 
be  included  to  simulate  the  effects  of  anticipated  retirements  and  to 
project  staffing  needs. 

The  particular  mix  of  such  "advanced"  features  in  an  application  will  depend 
as  much  on  the  personality  of  the  responsible  manager  as  on  organizational 
size  and  environment.    As  a  result,  while  the  functions  of  the  personnel 
application  will  be  comparable  from  site  to  site,  the  degree  of  automation  and 
the  provision  of  advanced  analysis  capabilities  will  vary. 

More  complex  applications  can  vary  from  the  typical  pattern  of  inter- 
connections shown  in  Figure  II-l.     For  example.  Figure  IV-2  shows  the  subsystem 
structure  of  an  advanced  logistics  planning  model  that  processes  data  on  all 
(expensive)  repairable  spare  parts  in  the  Air  Force  inventory.    The  difficulty 
of  the  problem  forces  a  series  of  models  to  process  data  in  sequence,  with  one 
model  supplying  inputs  to  the  next.     This  is  in  contrast  to  the  parallel 
organization  in  Figure  II-l,  where  each  model  is  implied  to  be  optional  and 
independent . 

In  the  logistics  planning  model,  there  is  extensive  transformation  of  data 
into  information.     The  data  retrieval  and  analysis  subsystem  shown  provides 
information  to  the  planners  —  it  presents  them  with  capability  estimates  in 
response  to  trial  budget  allocations  and  thereby  allows  them  to  make  better 
budgeting  decisions.     The  suggestion  model  shown  provides  information  to 
logistics  item  managers  concerning  which  parts  to  purchase.    The  original 
input  tapes  are  simply  not  useful  to  logistics  planners  for  budgeting  purposes: 
without  pre-processing,  the  mass  of  detail  is  impossible  for  a  decision-maker 
to  absorb.     Until  the  data  are  transformed  by  the  models,  and  presented  in  such 
a  way  that  a  decision-maker  can  make  decisions  and  take  actions,  it  cannot  be 
said  that  those  input  tapes  provide  information  —  only  that  the  potential  is 
there , 

This  section  has  introduced  the  concept  of  an  application  as  comprising 
different  DP  subsystems,  each  serving  as  a  module  or  building  block  for  the 
application.    Later  phases  of  this  effort  may  attempt  to  catalog  the  various 
ways  subsystems  are  combined  to  form  DP  applications  in  the  Federal  Government, 

C,     Subsystem  Operational  Characteristics 

The  DP  subsystems  presented  earlier  can  exhibit  different  operational 
characteristics  because  of  both  the  types  of  applications  in  which  they  are 
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included  and  the  skill  required  to  operate  them  and/or  utilize  their  products. 
Master  files  are  both  an  output  from  recordkeeping  systems  and  an  input  to 
transaction  disbursement  systems,  for  instance.     Transaction  aggregation 
systems  are  typically  used  by  clerical  personnel,  while  representational 
models  (in  specialized-data  model  subsystems)  are  generally  used  either  by 
economists  or  by  technical,  business,  or  policy  analysts. 

Table  IV-A  lists  different  operational  characteristics  for  subsystems  in 
several  categories  of  variation.     "Key  Role"  indicates  the  type  of  personnel 
most  responsible  for  the  successful  operation  of  the  subsystem.  "Decision- 
Maker"  indicates  the  type  of  personnel  acting  upon  subsystem  outputs.  The 
other  categories  are  self-explanatory. 

For  subsystems  8.1  through  11.2,  the  information  on  type  of  task,  hands- 
on-user,  decision  maker,  key  role,  and  key  usage  problem  comes  from  [ALTK-77]. 
The  following  definitions  from  Alter' s  1975  work  [ALTE-75,  ch.  6]  apply: 

o    Feeders  are  people  who  provide  data  for  a  system,  but  either  do 

not  use  it  directly  for  their  own  decisions  or  do  not  derive  benefit 
from  it  for  other  reasons.     This  role  is  common  in  budgeting  and 
planning  systems  in  which  people  at  various  organizational  levels 
are  required  to  provide  information  which  is  later  digested  and 
consolidated  by  the  system, 

o    A  user  is  a  person  who  communicates  directly  with  the  system  in  either 
on-line  mode  or  batch  mode  and  receives  and  decodes  its  outputs. 

o    A  decision-maker  is  a  person  who  makes  decisions  based  on  the  outputs 
of  the  system.     These  outputs  may  have  been  filtered  or  interpreted  by 
the  user  before  the  decision-maker  receives  them.     In  this  case,  the 
user  is  referred  to  as  an  intermediary. 

And,  in  the  context  of  subsystem  5, 

o    A  designer  is  the  programmer/analyst  and/or  electronics  engineer 

responsible  for  creating  hardware  and  software  linkages  to  sample  and 
record  the  process  data. 

Other  portions  of  the  table  are  postulated  from  a  general  knowledge  of 
DP  applications. 


Alter  covers  some  other  categories  as  well,  but  these  deal  with  system 
design  and  implementation  and  will  be  covered  under  the  descriptive  model 
for  application  software  development.     This  portion  of  Table  IV-A  reprinted 
with  permission  (see  references) . 

Reprinted  with  permission  of  the  author. 
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V.     ADDITIONAL  SUBSYSTEM  CONCEPTS 


A.  General 

The  previous  chapters  have  presented  a  descriptive  model  of  DP  operations. 
This  chapter  introduces  some  associated  concepts  which  further  develop  the 
framework.     It  also  describes  some  practical  uses  of  the  model  made  possible 
by  combining  those  concepts  with  the  earlier  subsystem  descriptions. 

B.  Micro  Layers  of  Description 

Each  of  the  descriptive  flow  diagrams  in  Appendix  B  characterizes  DP 
operational  subsystems  in  terms  of  the  interaction  between  employees,  data 
processing  steps,  and  various  media  containing  data.    The  types  of  personnel, 
processing,  and  data  are  indicated.     This  level  of  detail  is  a  process  descrip- 
tion:    it  shows  what  is  done  to  data,  by  whom,  and  in  what  sequence,  as  well 
as  what  kinds  of  data  (and,  if  desired,  which  data  elements)  are  present. 

While  this  level  of  detail  is  adequate  for  a  descriptive  model,  much  more 
information  is  necessary  to  evaluate  a  variety  of  computer-related  standards 
and  guidelines.    For  example,  it  could  be  important  to  the  evaluation  of 
certain  standards  to  know  what  percentage  of  the  data  input  terminals 
represented  in  Figure  B-2  employed  a  standard  ASCII  character  set.  Later 
phases  of  the  effort  will,  ultimately,  expand  the  descriptive  model  to  include 
such  data. 

This  expansion  will  be  accomplished  by  defining  additional  layers  of 
detail  within  the  constraints  and  patterns  of  interconnection  established  by 
the  process  descriptions.     Comparable  aspects  of  DP  system  activities  will  be 
grouped  within  the  same  layer.     For  example,  plugging  a  cable  into  a  terminal 
on  one  end  and  a  modem  on  the  other  requires  physical  standards  for  pin 
configurations  and  connector  dimensions.    This,  and  all  other  mechanical 
interactions,  would  be  included  in  descriptions  of  the  "physical  control" 
layer  of  the  model.    The  subsystems  represent  the  breadth  of  DP  activities; 
the  layers  of  detail  represent  the  depth  of  description. 

Much  of  the  subsequent  discussion  of  layers  may  not  be  familiar  to  the 
nontechnical  reader.    However,  for  the  purposes  of  this  report,  it  is  only 
necessary  to  have  a  general  understanding  that  information  about  DP  activities 
can  be  meaningfully  separated  into  layers  of  description. 

The  interactions  (flows)  between  the  blocks  in  each  subsystem  are 
the  key  to  incorporating  additional  information  into  the  descriptive  model 
framework.    The  layers  that  will  be  used  to  relate  the  important  character- 
istics of  each  flow  are  the  seven  layers  of  communication  standards  defined  by 
the  International  Standards  Organization  (ISO).     This  structure  was  selected 
because  it  is  compatible  with  existing  standards  and  covers  anticipated  future 
standards . 
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A  brief  description  for  each  layer  is  as  follows: 


(7)     process  control  -  the  high-level  events  and  steps  in  a  data 
processing  procedure,  including  the  personnel,  DP  equipment, 
software,  and  data  involved. 

(6)     presentation  control  -  functions  relating  to  character  sets, 
character  encoding,  and  the  presentation  of  character  data. 

(5)     session  control  -  procedures  for  establishing  the  rules  for 
how  a  dialogue  will  take  place  between  two  elements  (which 
machine  will  speak  and  in  what  sequence), 

(4)     transport  end-to-end  control  -  integrity  controls  for  the  flow 
of  transactions  between  two  user  devices  and/or  computers, 
insuring  completeness  of  transmission. 

(3)    network  control  -  procedures  for  establishing  a  route  for  data 
through  a  shared  network  (a  "virtual  circuit")  and  for  trans- 
mitting data  through  the  network. 

(2)     link  control  -  procedures  for  sending  blocks  of  data  over  a 
physical  transmission  line. 

(1)     physical  control  -  specifications  for  mechanical,  electrical, 
or  other  physical  interconnections  that  establish  a  trans- 
mission link  between  two  devices. 


Table  V-A  shows  these  layers,  and  lists  some  of  the  elements  and  processes 
found  in  each.^    For  example,  in  this  breakdown,  an  ASCII  character  set 
is  one  of  the  character  set  options  under  layer  6  (presentation  control),  and 
the  use  of  ASCII  would  be  recorded  as  a  layer  6  detail  of  the  descriptive 
model.     The  subsystem  descriptions  presented  earlier  have  involved  only  layer 
7  (process  control). 

These  layers  apply  to  all  system  interfaces.     For  example,  for  the  clerk 
in  Figure  B-2  to  use  a  terminal  to  communicate  with  a  computer,  or  for  any  of 
the  flows  in  the  subsystem  description  to  exist,  a  "compatible"  linkage  must 
be  established  between  terminal  and  computer  at  each  of  the  seven  layers. 
Compatibility  means  the  specification,  at  each  layer,  of  the  procedures  in 
use.     For  some  of  the  layers,  few,  if  any,  of  the  procedures  may  be  relevant 
to  the  interconnection.    For  example,  layer  3  (network  control)  procedures  do 
not  apply  to  most  timesharing  computer  users  who  dial  the  computer  center 
directly. 


The  level  of  the  interface  layer  is  indicated  by  the  number  in  parentheses. 

From  [MART-80] ,  but  "character  sets"  and  "data  representations"  have 
been  added  to  clarify  points  for  this  descriptive  model.     Reprinted  with 
permission  (see  references) . 
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TABLE  V-A 
SEVEN  ISO  LAYERS 


7.     PROCESS  CONTROL 

APPLICATION  &  APPLICATION  SYSTEM 
ACTIVITIES 

DATA  REPRESENTATIONS  (ABBREVIATION  &  CODING) 
OPERATOR  FUNCTIONS 
DISTRIBUTED  FILE  &  DATABASE 

6.     PRESENTATION  CONTROL 

CHARACTER  SETS 

DATA  FORMATS 

DATA  TRANSFORMATIONS 

EDITING 

COMPACTION 

CRYPTOGRAPHY 

VIRTUAL  DISPLAY  SPACE,  ETC. 

5.     SESSION  CONTROL 

ACTIVATE  AND  DEACTIVATE  SESSIONS 
BIND 

ENFORCE  DIALOGUE  CONTROL 
CHECKPOINTING  &  RECOVERY 

4.     TRANSPORT  END-TO-END  CONTROL 

DATA  ASSURANCE 
PACKETIZING,  ADDRESSING, 

FLOW  CONTROL 
tJETWORK- INDEPENDENCE  INTERFACE 

3.     NETWORK  CONTROL 

X.25  PACKET  LEVEL 
INTERFACE  TO  NETWORK 

2.     LINK  CONTROL 

HDLC,  ADCCP 

1.     PHYSICAL  CONTROL 

V.24,  V.25,  EIA  RS  232C,  EIA  RS  366 
X.21,  X.21  BIS 


From  [MART-80],  but  "character  sets"  and  "data  representations"  have 
been  added  to  clarify  points  for  this  descriptive  model.     Reprinted  with 
permission  (see  references) . 
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To  adapt  the  ISO  layers  concept  for  this  descriptive  model,  the  concept 
must  be  broadened.     For  instance,  ISO  layer  3  (network  control)  covers  the 
establishment  of  "virtual  circuits"  in  computer  networks.     The  descriptive 
model  layer  3  includes  much  simpler  cases  such  as  a  clerk' s  dialing  the  phone 
number  of  the  computer  center  or  an  installer's  connecting  a  hard-wired  cable 
at  one  point  in  time.    As  another  example,  layer  1  (physical  control)  often 
implies  the  use  of  a  standard  25-pin  electrical  connector.    However,  in  the 
broader  context  of  the  descriptive  model,  it  can  mean  any  physical  interface 
such  as  the  sound  waves  carrying  data  between  an  acoustic  coupler  on  a  terminal 
and  a  telephone  receiver  (an  energy  linkage)  or  one  employee  handing  a  piece 
of  paper  to  another  (a  physical,  "touching"  linkage). 

Possible  interfaces  at  the  different  descriptive  layers  could  be  described 
at  great  length,  and  a  later  phase  of  this  effort  may  cross-reference  the  set 
of  Federal  Information  Processing  Standards  to  the  descriptive  model  subsystems 
and  produce  some  interface  specifications.     The  present  purpose  is  simply  to 
show  that  the  descriptive  model  concept  is  not  limited  to  descriptions  of  DP 
procedures.     All  kinds  of  data  about  computer  systems  may  be  incorporated  into 
the  descriptive  model,  in  an  organized  fashion,  by  employing  the  micro  layers 
of  description  outlined  above. 

C.     Macro  Layers  of  Description 

Certain  broader  questions  of  interest  to  Federal  DP  activities  cannot  be 
represented  within  the  seven-layer  framework,  and  an  expansion  to  higher 
levels  is  needed.     For  example,  subsystem  1  (transaction  aggregation)  indicates 
that  transaction  documents  are  received  and  keypunched  but  does  not  imply  what 
kind  of  information  contained  in  the  transactions.     In  the  application 
illustrated  in  Figure  IV-1,  purchase  order  processing,  expense  information  is 
contained  in  the  transactions.     However,  subsystem  1  transactions  could 
contain  other  types  of  information  such  as  stock  level  changes.     As  indicated 
in  the  Chapter  IV  examples,  the  information  flowing  through  the  system  can 
change  as  additional  processing  is  performed,  depending  on  who  interprets  the 
data  and  in  what  context.     For  example,  repair  action  information  from  an 
airbase,  after  much  processing  and  aggregation,  eventually  becomes  budget 
planning  information.     Layer  8  (information)  will  be  designated  for  any 
discussion  of  the  interpretation  of  the  data  items  covered  in  the  descriptive 
model. 

The  benefits  of  standards  and  guidelines  that  affect  the  accuracy  and 
integrity  of  computer  processing,  most  notably  those  related  to  computer 
security,  will  primarily  depend  on  the  actions  taken,  and  the  decisions  made, 
based  on  the  data.     The  value  of  the  benefits  will  depend  on  the  financial  or 
other  impacts  of  those  actions  and  decisions.     Discussion  of  such  actions  and 
decisions  will  be  assigned  to  layer  9  (decisions). 

Decisions  are  generally  made  in  the  context  of  one  or  more  business  or 
organizational  functions,  and  layer  10  (organizational  functions)  is  designated 
for  information  on  organizational  functions  such  as  production,  accounting, 
personnel,  R&D,  etc.     Finally,  layer  11  (organizational  environment)  is 
provided  to  describe  the  organizational  environment  that  both  constrains  and 
motivates  DP  activities. 
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Table  V-B  shows  the  complete  11  layer  hierarchy  designed  to  organize 
DP  information  in  the  context  of  the  descriptive  model.    While  the  higher 
numbered  layers  will  not  be  utilized  immediately,  they  are  defined  here  to 
insure  that  a  robust  model  structure  will  be  available  when  needed.    The  next 
sections  further  elaborate  the  multi-layer  concept. 

D.      Security  Considerations 

The  descriptive  model  does  not  explicitly  include  computer  security. 
However,  combining  the  flow  diagrams  and  the  multi-layer  hierarchy  provides  a 
different  approach  to  categorizing  and  modeling  security  issues. 

Figure  V-1,  [WARE-79],  is  a  widely  used  representation  of  computer 
system  vulnerabilities.     It  provides  an  overview  of  threat  or  "leakage"  points 
for  computer  systems.    These  are  areas  where  a  system  designer  must  provide 
protective  features  to  safeguard  information  against  both  accidential  and 
deliberate  events.    They  may  be  classified  into  five  major  categories: 
physical  surroundings,  hardware,  software,  communication  links,  and  organ- 
izational aspects  (personnel  and  procedures). 

In  terms  of  the  definitions  given  earlier,  it  is  evident  that  Figure  V-1 
contains  a  mixture  of  elements  from  different  descriptive  layers.  Categorizing 
both  threats  and  system  vulnerabilities  in  terms  of  the  applicable  descriptive 
layers  makes  a  comprehensive  and  organized  treatment  of  computer  security 
possible.     Heretofore,  the  literature  has  been  characterized  by  a  plethora  of 
ad  hoc,  overlapping,  and  incomplete  security  categories,  which  have  varied 
with  the  interests  of  the  author.     The  combination  of  subsystem  flow  diagrams 
(covering  the  breadth  of  DP  activity)  and  a  multi-layer  descriptive  framework 
(covering  the  depth  of  DP  activity)  can  both  absorb  the  various  existing 
security  schema  and  provide  a  basis  for  analysis. 

In  any  functioning  DP  subsystem,  communication  between  layers  occurs  at 
many  of  the  interfaces  between  data  flows  (the  lines  in  the  subsystem  flow 
diagrams)  and  subsystem  elements  (the  boxes  in  subsystem  diagrams  —  processing 
or  action  steps,  and  storage  media).     When  a  user  enters  data  at  a  terminal  by 
striking  a  key  (layer  1),  the  terminal  translates  that  action  into  a  string  of 
bits  in  accordance  with  the  ASCII  standard  or  some  other  defined  character  set 
(layer  6),  other  bits  may  be  added  if  intermediate  levels  (2  through  5)  are 
active,  and  the  bit  stream  is  translated  into  electrical  impulses  (layer  1), 
Between  instances  of  communication  between  layers,  activities  or  data  flows  in 
all  active  layers  are  considered  to  occur  simultaneously  and  in  parallel. 

This  conceptualization  leads  to  several  principles: 

o    To  compromise  a  system,  a  perpetrator  must  be  able  to  detect  (and 

correctly  interpret)  data  flows  of  interest  at  all  layers  between  1  and 
8  that  are  in  use  at  his  point  of  system  access. 

o    To  manipulate  a  system,  a  perpetrator  must  be  able  to  compromise  the 
system  and  also  influence  or  control  at  least  one  layer  at  one  point  in 
a  subsystem. 
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TABLE  V-B 

MACRO  Mm  MICRO  LAYERS  OF  DESCRIPTION 


Layer 

11 

10 
9 
8 
7 
6 
5 
4 
3 
2 
1 


(MACRO) 
(PROCEDURAL) 
(MICRO) 


Title 

ORGANIZATIONAL  ENVIRONMENT  (GOALS,  RESOURCES, 
CHARACTERISTICS) 

ORGANIZATIONAL  FUNCTIONS 

DECISIONS 

INFORMATION 

PROCESS  CONTROL  ^ 

PRESENTATION  CONTROL 

SESSION  CONTROL 

TRANSPORT  END-TO-END  CONTROL 

NETWORK  CONTROL 

LINK  CONTROL 

PHYSICAL  CONTROL 


The  subsystem  descriptions  in  this  report  represent  the  process 
control  layer. 
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o    To  disrupt  a  system,  a  perpetrator  needs  only  to  disrupt  any  one  layer, 
which  may  be  accomplished  by  destroying  data,  inserting  noise,  or 
severing  linkages.     It  is  not  necessary  for  the  perpetrator  to  possess 
the  in-depth  knowledge  of  system  processing  that  might  be  required  to 
accomplish  a  compromise  or  manipulation, 

o    Errors  and  omissions  need  occur  only  at  one  level,  like  disruptions. 

As  an  illustration,  to  compromise  a  system  by  wiretapping,  a  perpetrator 
must  be  able  not  only  to  detect  the  electrical  impulses  in  the  phone  line 
(layer  1)  but  also  correctly  interpret  those  impulses  as  characters  (layer  6) 
in  order  to  gain  information  (layer  8).     Secure  encryption  prevents  the 
perpetrator  from  correctly  interpreting  any  text  (in  layer  6)  to  get  to  the 
information  desired  (in  layer  8).     It  is  more  difficult  to  manipulate  a  system 
by  interrupting  telephone  communications.     The  perpetrator  has  to  not  only 
insert  new  signals  but  also  have  full  knowledge  of  the  higher  layers  if  the 
new  signals  are  to  have  the  desired  effects  on,  say,  the  data  presentation 
(layer  6),  while  not  affecting  any  intervening  layers  in  a  way  that  can  be 
detected. 

To  disrupt  a  system  communication,  the  perpetrator  need  only  cut  the 
telephone  line  or  inject  noise  into  it  (layer  1);  there  is  no  need  to 
manipulate  or  compromise  the  higher  numbered  layers.     More  extensive  disrup- 
tions require  either  more  extensive  or  more  critical  physical  destruction,  or 
an  ability  to  manipulate  the  lower  layers  so  as  to  disrupt  the  system  at 
higher  layers.    An  instance  of  the  latter  is  the  submission  of  a  program  that 
in  fact  "takes  over"  an  operating  system. 

Detected  errors  or  omissions  are  in  general  a  form  of  disruption  —  they 
cause  additional  work  to  be  performed  to  straighten  them  out,  and  they  slow 
down  operations.     Undetected  errors  and  omissions  are  like  manipulations  — 
they  cause  improper  actions  as  they  flow  through  a  system. 

In  addressing  security  issues,  layers  9  through  11  must  be  considered 
twice  —  once  for  the  perpetrator  and  once  for  the  victim  organization.  The 
first  instance  involves  the  perpetrator  point  of  view  and  addresses  the  costs 
and  benefits  of  attacking  the  system;  the  second  addresses  both  the  costs  of 
protecting  the  system  from  attack  and  the  potential  losses  from  not  protecting 
the  system,  using  the  organization's  point  of  view.     Both  sets  of  costs  and 
benefits  must  be  considered  in  the  selection  of  security  measures. 

Both  threats  and  protective  measures  can  be  cross-indexed  in  terms  of 
subsystems  and  descriptive  layers.     This  provides  a  powerful  tool  for  security 
analysis,  and  is  an  illustration  of  how  security  issues  may  be  incorporated 
into  these  descriptive  models. 


E.     Presentation  Methods 

The  set  of  descriptive  flow  diagrams  presented  in  Appendix  B  can  be  used 
for  more  visually-oriented  presentations  of  the  impacts  of  standards. 
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Figure  V-2  illustrates  how  the  impacts  of  a  hypothetical  standard  could  be  cross- 
referenced  to  points  of  impact  in  the  descriptive  model.    This  illustration 
shows  only  the  aggregate  totals  for  major  impact  areas,  but  other  headings, 
such  as  detailed  impact  areas, 3  could  be  used  if  more  space  were  available. 

While  the  "Impact  Areas"  columns  contain  dollar  impacts,  the  "Impact 
Descriptions"  columns  contain  commentary  text.    The  "Specific  Impacts"  column 
would  show  which  system  characteristics  would  be  influenced  by  the  standard  in 
order  to  achieve  the  projected  impacts.    The  "Measurements"  column  would  list 
the  data  characteristics  to  be  measured,  the  data  to  be  collected,  the 
methodology  to  be  employed  in  data  collection  and  analysis,  and  estimates  of 
probable  error. 

Another  use  for  this  type  of  format  would  be  to  cross-reference  impact 
categories  and  different  standards  and  guidelines  in  a  family  or  even  different 
families.     Such  a  presentation  would  highlight  possible  cross-impacts  and 
indicate  the  need  to  explore  whether  the  standards  were  complementary  or  in 
conflict.     Standards  could  also  be  grouped  by  other  criteria  such  as  the 
descriptive  layer  affected  or  the  specific  points  of  impact  in  each  subsystem. 


Table  A-1  in  Appendix  A  lists  impact  areas. 
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VI.  CONCLUSION 


A.  Summary  of  Phase  I  Report 

This  report  has  presented  flow-diagram  descriptions  for  a  set  of  DP 
operational  subsystems.    These  diagrams  and  the  specifications  for  the  sub- 
systems are  the  basic  elements  for  a  descriptive  model  of  Federal  DP 
operational  activities.    The  subsystems  serve  as  building  blocks  for  computer 
applications.     Different  applications  can  comprise  the  sane  combinations  of 
subsystems  —  the  processing  can  be  similar  even  though  the  data  items  are 
different  and  serve  different  parts  of  an  organization. 

It  will  be  useful  for  analytical  purposes  to  associate  information  about 
system  standards  and  guidelines  and  their  impacts  with  the  descriptive  model. 
This  may  be  accomplished  through  use  of  the  multiple  descriptive  layers 
presented  Chapter  V.    The  layers  characterize  interfaces  between  elements  in 
the  descriptive  flow  diagrams.     The  concept  is  particularly  useful  for  analyz- 
ing security  issues,  since  security  violators  generally  must  access  a  system 
using  the  same  types  of  interfaces  as  system  users,  and  analysis  by  layers 
allows  a  more  precise  treatment  of  those  interfaces.    A  brief  overview  was 
given  of  potential  uses  of  the  descriptive  model  for  presenting  interrelation- 
ships between  DP  systems  and  standards. 

B.  Future  Work 

During  later  study  phases,  the  breadth  of  the  Phase  I  descriptive  models 
will  be  extended  by  the  preparation  of  additional  descriptive  models  for 
hardware  acquisition,  software  acquisition,  application  software  development, 
data  resources  planning,  security,  and  overall  DP  management.     Eventually,  all 
secondary  areas  shown  in  Figure  I-l  should  be  developed  to  a  stage  comparable 
to  the  model  presented  in  this  report  for  DP  operations. 

The  focus  of  the  Phase  II  effort  is  the  development  of  descriptive  models 
for  applications  software  development.     The  Phase  II  model  traces  the  unifying 
flow  from  initial  problem  to  ultimate  software  solution,  and  intersects  the 
Phase  I  model  in  subsystem  13,  which  in  turn  may  intersect  the  remaining  12 
subsystems  at  any  point  where  in-house  software  is  utilized.     In  addition,  a 
parallel  effort  on  a  security-related  descriptive  model  is  now  underway. 
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APPENDIX  A 


BASIC  COST-BENEFIT  ANALYSIS 
METHODOLOGY 


APPENDIX  A 
BASIC  COST-BENEFIT  ANALYSIS  METHODOLOGY 


1.  Specifying  the  Goals  and  Objectives  for  the  Standard.     Identifies  which 
ICST  goal(s)  and  objectives(s)  the  prospective  standard  is  expected  to 
contribute  to  and  achieve,  respectively. 

2.  Preparing  the  Standards  Definition  Statement.     Summarizes  all  the 
essential  information  about  the  standard  necessary  to  conduct  the  cost- 
benefit  analysis.    At  a  minimum  this  includes: 

-  How  the  standard  will  be  developed,  used  and  supported. 

-  Essential  assumptions  and  information  for  the  cost  and  benefit 
estimates  submitted. 

-  The  historical  data  trail  on  the  evolution  of  the  standard's  design 
and  development  and  the  corresponding  impact  and  cost  estimates  from 
the  beginning  to  the  formal  implementation  of  the  standard.     The  trail 
is  provided  by  the  chronological  sequence  of  updated  definition 
statements . 

-  A  basis  for  a  critical  review  of  the  standard's  objectives  and  a 
discussion  on  how  well  the  proposed  design  and  development  process 
will  satisfy  them. 

-  Descriptions  of  the  areas  of  high  technological  risk  and  cost-benefit 
uncertainty. 

The  statement  can  also  reference  selected  information  in  the  backup 
material  that  documents  the  cost  and  benefit  estimates.    Each  time  a 
cost-benefit  analysis  is  prepared,  a  Standards  Definition  Statement  will 
also  be  prepared.     In  this  way,  the  statement  provides  a  readily 
available  audit  trail  and  a  basis  for  critical  review  of  the  standard. 

3.  Defining  the  Base  Case.    Defines  the  status  quo  for  those  cost-benefit 
impact  dimensions  relevant  to  the  standard.    The  base  case  can  be  defined 
for  one  or  several  FIPS  that  are  under  consideration.    The  several 

FIPS  case  would  occur  where  the  impacts  from  two  or  more  alternatives  tend 
to  overlap,  and  the  individual  impacts  are  not  readily  distinguishable. 
It  also  provides  a  basis  for  the  projection  of  future  conditions  if  the 
standard  is  not  developed  and  implemented. 


Based  on  the  1978  preliminary  guidelines  for  impact  assessments  of 
standards  [FIOR-78]. 
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4.  Selecting  the  Cost-Benefit  Impact  Areas.     Specifies  cost  and  benefit 
Impact  areas  relevant  to  the  standard,     A  standard  will  require  certain 
costs  for  development,  Implementation,  validation  and  maintenance.  In 
addition,  there  are  costs  that  can  be  Incurred  by  the  Federal  ADP 
installations  that  utilize  the  standard.     On  the  benefit  side,  a  standard 
will  typically  tend  to  have  its  major  economic  impacts  in  one  of  three 
areas:     procurement,  operations,  or  conversion.    These  impact  areas  and 
elements  further  delineate  how  a  standard  contributes  to  the  ICST  goals 
and  objectives  concerned  with  achieving  economies  in  ADP  procurement, 
operations,  and  conversion.     Table  A-1  gives  the  list  of  impact  areas. 

5.  Constructing  the  Cost-Benefit  Analysis  Model.     Provides  the  appropriate 
model  form  to  quantify  the  cost  and  benefit  impacts  expected  of  the 
standard.     The  model  is  used  to  estimate  the  flows  of  costs  and  benefits 
attributable  to  the  standard  over  time.    Adjustments  for  the  time  value  of 
money  can  be  incorporated  in  the  model  by  using  appropriate  discount 
factors. 

6.  Obtaining  Data.     Collects  the  data  to  perform  the  analysis.     In  addition 
we  expect  to  utilize  the  data  and  analyses  from  the  cost-benefit  analysis 
of  selected,  individual  standards. 

7.  Estimating  and  Evaluating  the  Cost-Benefit.     Represents  the  consolidation 
of  the  qualitative  and  quantitative  analyses  performed  up  to  this  point. 
The  basis  of  the  cost-benefit  analysis  will  be  the  generation  of  the  base 

-case  parameters  and  the  computation,  within  specific  confidence  intervals, 
of  the  effect  a  new  standard  scenario  will  have  on  cost  levels.  The 
techniques  used  to  generate  the  figures  comprising  the  base  case  address 
the  areas  of:     (1)  level  of  expected  resource  consumption,     (2)  Federal 
ADP  installation's  unit  cost  for  each  resource,  and  (3)  projected 
impact(s)  of  the  proposed  ADP  standard.     To  aid  in  this  process,  cost 
element  equations  will  be  used.     To  determine  the  net  cost-benefit  impact 
of  a  FIPS,  the  costs  to  the  Federal  Government  (specifically  ICST)  of 
developing  and  implementing  the  FIPS  will  be  defined  and  incorporated  into 
the  analysis. 

8.  Presenting  and  Interpreting  the  Results.     Translates  the  cost-benefits 
attributable  to  the  FIPS  in  the  context  of  the  Federal  agencies  that  are 
expected  to  be  impacted  by  the  standard.     This  step  is  crucial  as  it 
specifies  whether  actual  budget  dollars  will  be  changed  (such  as  in 
procurement  impacts)  or  whether  the  impacts  are  productivity  changes  (such 
as  when  a  resource  is  freed  up  for  other  activities). 
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TABLE  A-1 
COST-BENEFIT  IMPACT  ELEMENTS 


100  PROCUREMENT 

101  Hardware 

102  Software 

103  Testing 

104  Planning  &  Analysis 

105  Initial  Training 

106  Documentation 

107  Installation 

200  OPERATIONS 

201  Operating 

202  System  Management 

203  Maintenance 

203.1  Hardware  Maintenance 

203.2  Software  Maintenance 

204  Programming 

205  Ongoing  Training 

206  Facilities 

207  Security  Provisions 

300  CONVERSION 

301  Program  Transfer 

302  Retrofit 

400     SYSTEM  PERFORMANCE 

401  Computer  System 

402  Applications  Software 

403  System  Users 

500     COMPUTER  MISUSE 

501  Errors  and  Omissions 

502  Computer-Related  Fraud  and  Embezzlement 

503  Privacy  Intrusion 

504  Alteration  of  Computer  Records 

505  Theft  of  Computerized  Information 

506  Unauthorized  Usage 

507  Denial  of  Service 

508  Equipment  Damage 
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SUBSYSTEM  DESCRIPTIVE  MODELS 


Overview 

This  Appendix  contains  flow  diagrams  to  illustrate  representative 
processing  procedures  for  the  13  operational  subsystems  defined  in  the 
text. 

These  flow  diagrams  are  a  breakdown  of  Data  Processing  Operations  as 
represented  in  Figure  I-l ,  and  may  be  viewed  as  existing  in  that  larger 
context.     Technology  variations  and  interactive  vs.  batch  options  are  shown 
where  appropriate  within  each  flow  diagram,  with  the  exception  of  subsystem  3 
(recordkeeping),  where  two  separate  flow  diagrams  were  used  to  represent  the 
differences  between  "standard"  and  DBMS  processing.     Exhibit  B-1  introduces 
the  symbols  used  in  the  flow  diagrams  and  notes  extensions  to  the  standard 
sj^bols  shown  in  Exhibit  B-2, 
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Exhibit  B-1.    KEY  TO  ILLUSTRATIONS 


The  subsystem  flow  diagrams  in  this  Appendix  have  been  prepared  in 
accordance  with  FTPS  PUB  24  [ICST-73],  which  adopts  the  flowchart  symbols 
specified  in  [ANSI-71].     However,  for  the  purposes  of  these  flow  diagrams,  the 
extensions  noted  below  were  necessary  to  provide  uniformity  and  clarity  of 
representation.     Please  refer  to  Exhibit  B— 2  for  a  summary  of  the  standard 
symbols . 


(ANNOTATIONS)  and  COMMENTS 

Interfaces  between  users  and 
subsystems 


The  combination  of  "manual  input"  and 
"display"  shown  here  represents  any 
user-interactive  terminal ,  which  may  be 
a  CRT,  printing  terminal,  or  CRT  with 
attached  printer.     The  symbol  may  have 
either  a  left-  or  right-  orientation 
in  order  to  face  the  illustration  of  a 
user  in  a  flow  diagram. 


The  on-line  storage  symbol  is  used  to 
represent  either  tape,  disk,  or  other 
storage  media  accessible  on-line,  in 
accordance  with  FTPS  PUB  24.  However, 
its  usage  includes  instances  where  the 
more  specific  magnetic  disk  symbol 
would  have  been  more  correct.     This  was 
done  in  order  to  reserve  the  magnetic 
disk  symbol  for  the  emphasis  of  part- 
icular technology  variations  and/or 
database  random  access  in  the  appropriate 
subsystems . 


(DISPLAY) 


USER 


(MANUAL  INPUT) 


(ON-LINE  STORAGE) 
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Exhibit  B-2.     Summary  of  Flowchart  Symbols 
Basic  Symbols 


Input/Output 


Process 


Flowline 


Crossing  of 
Flowlines 


Junction  of 
Flowlines 


Annotation,  Comnnent 


Specialized  Input/Output  Symbols 


Punched  Card 


Deck  of  Cards 


File  of  Cards 


Online  Storage 


Magnetic  Tape 


Punched  Tape 


Magnetic  Disk 


Core 


Document 


Manual  Input 


Display 


Communication 
Link 


Magnetic  Drum 


Offline  Storage 


From  [ANSI-70] 
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Summary  of  Flowchart  Symbols 
Specialized  Process  Symbols 


(Continued) 


Decision 


Predefined 
Process 


Preparation 


Manual 
Operation 


Additional  Symbols 


Connector 


Parallel  Mode 
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